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© Booting a computer system using a last known good set of configuration data. 



® The present invention provides a current set of 
configuration data to be used in a first attempt to 
boot the computer system, and the LastKnownGood 
set of configuration data which stores the last set of 
configuration data that successfully booted the com- 
puter system. The present invention first attempts to 
boot the computer system from the current set of 
configuration data. In response to an unsuccessful 
r- attempt to boot the computer system using the cur- 
^ rent set of configuration data, the present invention 
^ automatically boots the computer system using the 
fs LastKnownGood set of configuration data. In re- 
0> sponse to a successful boot of the computer system 
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using the LastKnownGood set of configuration data, 
the present invention makes a new current set of 
configuration data that is equivalent to the Last- 
KnownGood set of configuration data that success- 
fully booted the computer system. In response to a 
successful boot from the current set or configuration 
data, the present invention makes a new LastKnown- 
Good set of configuration data that is equivalent to 
the current set of configuration data which success- 
fully booted the computer system. If boot appears to 
succeed to software, but fails in a way apparent to a 
human user, the system may be manually forced to 
use the LastKnownGood configuration set. 
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Technical Field 

This invention relates generally to a method 
and system for booting a computer, and more 
specifically, to a method and system which en- 
sures that the boot-up procedure will always be 
successful. 

Background or the Invention 

When a user starts a personal computer sys- 
tem, the computer system goes through a complex 
set of operations to make sure that all of its com- 
ponents are working properly. This operation is but 
the first step in an even more complicated process 
called the system boot-up procedure (i.e., the 
boot). Booting the system activates all of the com- 
puter system's components long enough to load an 
operating system. The operating system is a com- 
puter program that allows the computer system to 
use other computer programs. Before attempting to 
load the operating system, the computer system 
insures that the system's input-output hardware, 
central processing unit, and main memory are all 
functioning. This is accomplished through the use 
of a power-on self-test, or Post. 

After the Post checks all of the hardware com- 
ponents of the computer system, a boot program 
contained in the computer's ROM BIOS chips 
checks drive A of the computer to see if drive A 
contains a formatted floppy disk. If a formatted 
floppy disk is positioned in drive A, then the boot 
program loads the first sector of the disk into 
memory and executes it. If there is no formatted 
floppy disk in drive A, then the first sector on the 
first hard drive is loaded into memory and ex- 
ecuted. 

The first sector on the hard drive contains a 
program that reads the partition table of the hard 
drive and determines which partition is marked 
active. The first sector from the active partition is 
then loaded into memory and executed. 

The first sector on the active partition or floppy 
disk contains a program that searches for files that 
comprise the first files of the operating system. On 
most personal computer systems, the files are 
named IO.SYS and MSDOS.SYS. On IBM comput- 
ers, the two files are named IO.SYS and IBM- 
DOS. COM. For purposes of this discussion, it will 
be assumed that the two system files are IO.SYS 
and MSDOS.SYS. IO.SYS provides a low level in- 
terface to the ROM BIOS device routines. 
MSDOS.SYS is the DOS program itself and pro- 
vides a high-level interface for user programs. It 
consists of file management routines, data bloc- 
king/deblocking for the disk routines, and a variety 
of built-in functions easily accessible by user pro- 
grams. When these function routines are invoked 



by a user program, they accept high-level informa- 
tion via register and control block contents, then 
translate the requirements into one or more calls to 
IBMBIO.COM to complete the request. 

5 The boot record takes control of the computer 

system and loads the two operating system files 
into memory. The IO.SYS file contains extensions 
to the ROM BIOS and includes a routine called 
SYSINIT that manages the rest of the system boot 

w procedure. After loading IO.SYS, the boot record is 
replaced in memory by other program code, and 
SYSINIT assumes control of the system boot pro- 
cedure. In doing so, SYSINIT loads MSDOS.SYS 
into memory. SYSINIT then searches the root di- 

75 rectory of the computer memory for a file named 
CONFIG.SYS. If CONFIG.SYS exists in the com- 
puter system, then SYSINIT requests that 
MSDOS.SYS execute the commands in the CON- 
FIG.SYS file. CONFIG.SYS is a file created by the 

20 computer user and contains commands which tell 
the operating system how to handle certain oper- 
ations, such as how many files may be opened at 
one time, and how many system buffers may be 
used at any one time. CONFIG.SYS also contains 

25 instructions to load device drivers. A device driver 
is a program that the operating system uses to 
control hardware that communicates with the com- 
puter system. For example, MS-DOS uses a device 
driver to control how information is written to and 

30 read from a floppy disk drive. MS-DOS also has 
built-in device drivers for the computer system 
keyboard, monitor, hard drives, and communication 
ports. 

Next, SYSINIT tells MSDOS.SYS to load the 
35 file C0MMAND.COM. One function of COM- 
MAND.COM is to search the root directory of the 
computer memory for a file named 
AUTOEXEC.BAT. AUTOEXEC.BAT is a file created 
by the computer user and contains a series of MS- 
40 DOS batch file commands and/or the names of 
programs that the user wants to run each time the 
computer system is actuated. Typically, the com- 
puter system is now fully booted and ready to be 
used. 

45 However, as new hardware components are 

added to the computer system or as user needs 
change, it becomes necessary to modify the two 
user created system boot files, CONFIG.SYS and 
AUTOEXEC.BAT. Prior art systems allow the user 

50 to add and change CONFIG.SYS commands or 
AUTOEXEC.BAT commands to configure the com- 
puter system to suit the user's needs. To edit the 
CONFIG.SYS file, the MS-DOS editor or a text 
editor that saves files as unformatted (ASCII text) is 

55 typically used. Once the changes to the CON- 
FIG.SYS file or the AUTOEXEC.BAT file have been 
completed, the user must restart the computer 
system in order to have the changes take effect 
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because MS-DOS reads the CONFIG.SYS file and 
the AUTOEXEC.BAT file only during the boot-up 
procedure {i.e., when the computer system is start- 
ed). 

Occasionally, the changes to the CONFIG.SYS 
file or the AUTOEXEC.BAT file will cause the com- 
puter system to "hang" (i.e., not boot) in a way that 
prevents the user from editing, and therefore cor- 
recting, the system boot files. For example, in 
some cases where the system boot files are un- 
usable, the device driver for the computer system's 
hard drive cannot be loaded. Therefore, the system 
boot files stored on the hard drive cannot be ac- 
cessed or edited. In order to overcome this dead- 
lock the user must load an operating system such 
as MS-DOS from a floppy diskette. The user then 
edits the system boot files using the operating 
system editor and attempts to reboot the computer 
system using the edited system boot files on the 
hard drive. This process continues until the com- 
puter system is successfully booted. 

It would be desirable to have a computer sys- 
tem which automatically boots even if some con- 
figuration data has become unusable so that the 
user or the computer system can access the sys- 
tem boot files without the need of loading addi- 
tional files from external storage medium. 

Summary of the Invention 

The present invention provides a method and 
system to boot a computer system even after 
some configuration data has become unusable. 
This is accomplished by a method and system for 
booting the computer system from a set of configu- 
ration data that last booted the system properly. 
The present invention first attempts to boot the 
computer system from a current set of configura- 
tion data. If the attempt is unsuccessful, the 
present invention automatically boots the computer 
system using the last set of configuration data 
which successfully booted the computer system 
and which was previously stored. In response to a 
successful boot of the computer system using the 
last set of configuration data that properly booted 
the computer system, the present invention makes 
a new current set of configuration data that is 
equivalent to the last set of configuration data that 
successfully booted the computer system. 

If the attempt to boot from the current set of 
configuration data is successful, the present inven- 
tion stores it as the last set of configuration data 
that successfully booted the computer system. 

Brief Description of the Drawings 

Figure 1 is a block diagram of a system em- 
bodying the present invention for booting a com- 
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puter system. 

Figure 2 is a preferred tree structure of the 
System hive for the registry of Figure 1 . 

Figure 3 is a preferred tree structure for a 
5 Control subkey of the System hive. 

Figure 4 is a preferred tree structure for a 
Services subkey of the System hive. 

Figure 5 shows a preferred structure of a node 
under the Services subkey of the System hive. 
10 Figure 6 is a flow diagram of the method 
BootSystem for the system of Figure 1 . 

Figure 7 is a flow diagram of a method 
ChooseControlSet for the system of Figure 1 . 

Figure 8 is a flow diagram of the method 
75 InitializeRegistry for the system of Figure 1 . 

Figure 9 is a flow diagram of a method Load- 
DeviceDrivers for the system of Figure 1. 

Figure 10 is a flow diagram of a method In- 
itializeDevice Drivers for the system of Figure 1. 
20 Figure 11 is a flow diagram of a method Up- 
dateRegistry for the system of Figure 1 . 

Figure 12 is a flow diagram of a method Man- 
ageLastKnownGoodMenu for the system of Figure 
1. 

25 Figure 13 is a flow diagram of a method Pres- 

sOn for the system of Figure 1 . 

Figure 14 is a flow diagram of a method Up- 
date LastKnownGood for the system or Figure 1 . 
Figure 15 is a block diagram of a preferred 
30 LastKnownGood user interface menu. 

Detailed Description of the Invention 

The present invention provides a method and 
35 system for successfully booting a computer system 
100 (Figure 1) even after some configuration data 
has become unusable. For illustrative purposes, the 
present invention will be described as residing in 
the Windows NT™ operating system of Microsoft 
40 Corporation, Redmond, Washington. The compo- 
nents of a preferred operating system 101, all of 
which are preferably stored in a computer memory 
103, boot a computer 105 {i.e., "the system") using 
configuration data stored in a registry 107. Before 
45 discussing the operation of the present invention in 
detail, it will be helpful to understand how configu- 
ration data is preferably stored within the computer 
system 100 of Figure 1. 

so The Registry: 

The registry 107 is a unified and centralized 
data base for storing operating system, application, 
and hardware configuration data. The registry 107 
55 preferably stores this data in a hierarchical form 
which supports multiple users. Thus, the registry 
107 eliminates the need for multiple configuration 
files such as AUTOEXEC.BAT, CONFIG.SYS, and 
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other such configuration data files. 

The registry 107 is preferably structured as a 
tree. The preferred tree of the registry 107 is 

named: H KEY__LOC AL M ACH I N E Tree 131 

(which is described in more detail below and is 
shown in Figures 2, 3, 4, and 5). The 

HKEY LOCAL MACHINE Tree 131 contains data 

about the local computer system. This data in- 
cludes hardware and operating system characteris- 
tics such as bus type, system memory, installed 
device drivers, and boot configuration data (also 
known as boot control data). 

Each of the trees' nodes or keys are named. 
Each key may contain zero or more data items 
called value entries which are associated with the 
key. Keys are analogous to directories while value 
entries are analogous to files. A standard syntax 
used with the present invention defines names that 
begin with "\" as key names, and defines names 
that are followed by " = " as value entries, i.e., 
attributes of a key, as illustrated by way of example 
in Figure 2 

Physically, the registry 107 exists as a set of 
files on a hard disk (not shown). For the purpose of 
creating these files, the registry 107 is divided into 
sections called hives. Each hive maps directly to a 
file on the hard disk. 

The data in the System hive of the registry 107 

(i.e., H K E Y LO C AL MAC H I N E Tree 131 System) 

is organized into control sets. A control set is 
simply an instance or a set of system parameters. 
Figure 2 shows a preferred tree structure of the 
System hive. Each key in the System hive will now 
be described in more detail. 

Each key named ControlSetnnn 201-203 de- 
scribes a different configuration for the computer 
105. Each ControlSetnnn preferably resides in a 
non-volatile store. The clone 204 is a copy or the 
ControlSetnnn that is currently used to attempt 
system boot, made very early in the boot process, 
before any change to the current control set has 
occurred. The clone 204 is preferably stored in 
volatile memory. 

Each ControlSetnnn key has two subkeys, a 
Control subkey 206 (shown in more detail in Figure 
• 3) and a Services subkey 207 (shown in more 
detail in Figures 4 and 5). The Services subkey 
207 lists ail of the entities that can be loaded and 
set to running by the boot process on the computer 
105. Each subkey name listed in Figure 4 de- 
scribes a different device driver to install on the 
computer system 100. A device driver is a software 
component that permits the computer system 100 
to communicate with a device. For example, a 
printer driver is a device driver that translates com- 
puter data into a form understood by a printer (not 
shown) connected to the computer system 100 
through the input/output unit 125. Those of ordinary 



skill in the art will understand that different com- 
puter systems will list different entities under the 
Services subkey 207. Likewise, different computer 
systems will assign different values to the value 

5 entries shown in Figure 4. 

The Control subkey 206 holds all of the mis- 
cellaneous values needed to boot the computer 
105. 55For example, a value entry ser- 
vice_group_order 301 (Figure 3) of the Control 

w subkey 206 describes an order in which to invoke 
device drivers used by the computer system 100. 

As will be described in more detail below, the 
ControlSetnn keys, along with the clone 204, pre- 
vent unusable configuration data from creating a 

75 computer that cannot be started. When unusable 
configuration data initially prevents the system from 
starting, the present invention searches a Select 
key 205 (discussed in more detail below) and re- 
trieves the last control set that was successfully 

20 used to boot the computer 105. The present inven- 
tion then uses the retrieved control set to complete 
the system boot procedure. 

The Select key 205 maintains information 
about the control sets. The Select key 205 prefer- 

25 ably contains the value entries Current 208, Default 
209, LastKnownGood 210, Failed 211, and Auto- 
Select 212 (see Figure 2). Current 208 contains a 
data value that represents the control set that the 
computer 105 is currently booting from (i.e., a 

30 Current control set 208). Default 209 contains a 
data value that identifies a default control set (i.e., 
a Default control set 209) LastKnownGood 210 
contains a data value that identifies a control set 
containing the data values that last successfully 

35 booted the computer 105 (i.e., a LastKnownGood 
control set 210). Failed 211, if set, identifies the 
control set that failed when the LastKnownGood 
control set 210 was last used (i.e., a Failed control 
set 211). AutoSelect 212 contains a data value that 

40 controls whether a LastKnownGood user interface 
menu will be displayed. The LastKnownGood user 
interrace menu allows the user to choose whether 
to boot the computer 105 from the LastKnownGood 
control set 210 or by the Default control set 209. 

45 To retrieve the Current control set 208, the 
Default control set 209, the LastKnownGood control 
set 210, or the Failed control set 211, the operating 
system 101 (1) retrieves the data value stored in 
the value entry Default 209, Current 208, Failed 

so 211, or LastKnownGood 210, respectively, (2) for- 
mats this data value as a zero filled three digit 
string (e.g., 001), and (3) appends this three digit 
string to the end of the string "ControlSet" to arrive 
at the name of the control set to select (e.g., 

55 ControlSet001). 

A discussion of how the components of the 
preferred operating system 101 interact to boot the 
computer 105 using the control set indicated by 
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the value entry LastKnownGood 210 of the registry 
107, will help illustrate the method and system of 
the present invention. 

General Operation: 

In response to a user requestto boot the com- 
puter 105 received via an input/output unit 125, the 
computer 105 executes a boot system program 
109 of the operating system 101 to manage the 
system boot procedure for the computer 105. The 
BootSystem program 109, when executing on a 
central processing unit (CPU) 127, invokes a 
ChooseControlSet program 113 which chooses a 
set or configuration data (i.e., a control set) with 
which to boot the computer 105. The ChooseCon- 
trolSet program 113 will either choose the Default 
control set 209 or the LastKnownGood control set 
210 of the registry 107. The BootSystem program 
109 then invokes an InitializeRegistry program 111 
which, when executing on the CPU, 127, retrieves 
configuration data for the computer 105 and stores 
the retrieved configuration data in the registry 107. 
Next, the BootSystem program 109 invokes a 
LoadDeviceDrivers program 121 which, when ex- 
ecuting on the CPU 127, attempts to load and 
initialize a set of device drivers listed in the chosen 
control set. Figure 1 shows a state of the system 
101 after the device drivers 129 have been loaded 
into computer memory 103. If any of the device 
drivers should fail to load or initialize, then the 
LoadDeviceDrivers program 121 decides whether 
the system boot procedure currently underway 
should continue in spite of the failure to properly 
initialize the device driver, or whether a new sys- 
tem boot procedure should be initiated using the 
LastknownGood control set 210 of the registry 107. 

If a decision is made to reboot the computer 
105 using the LastKnownGood control set 210 then 
the system boot procedure is reinitiated using the 
configuration data stored in the LastKnownGood 
control set 210. Upon a successful boot of the 
computer 105, using either control set, the Boot- 
System program 109 invokes the UpdateRegistry 
program 123. In response to a successful boot 
from the Default control set 209, the UpdateRegis- 
try program 123 makes a new LastKnownGood 
control set 210 that is equivalent to the Default 
control set 209 which successfully booted the com- 
puter 105. The method UpdateRegistry, in re- 
sponse to a successful boot of the computer 105 
using the LastKnownGood control set 210, causes 
the Default control set 209 to be set to the Current 
control set 208 that successfully booted the sys- 
tem, and creates a new LastKnownGood control set 
210 that is equivalent to the Current control set 208 
that successfully booted the computer 105. In this 
way the present invention ensures that the com- 



puter 105 will successfully boot even after some 
configuration data in the Default control set 209 has 
become unusable. 

5 Row Diagrams: 

Figure 6 is a flow diagram of the method 
BootSystem which controls the system boot proce- 
dure for the computer 105. The method Boot- 

10 System is preferably performed by the BootSystem 
program 109. In step 601 the method BootSystem 
calls the method ChooseControlSet which chooses 
a set of configuration data (i.e., a control set) with 
which to boot the computer 105. The method 

75 ChooseControlSet will choose either the Default 
control set 209 or the LastKnownGood control set 
210 of the registry 107. The method ChooseCon- 
trolSet is discussed in more detail below and is 
shown in Figure 7. In step 603 the method Boot- 

20 System calls the method InitializeRegistry which 
retrieves configuration data for the computer 105 
and stores the retrieved configuration data in the 
registry 107. The stored configuration data is used 
to boot the computer 105. The method In- 

25 itializeRegistry is discussed in more detail below 
and is shown in Figure 8. Once the proper control 
set has been chosen and the registry has been 
initialised, the method BootSystem, in step 605, 
calls the method LoadDeviceDrivers. The method 

30 LoadDeviceDrivers loads into the computer mem- 
ory 103 and initializes a set of device drivers listed 
in the chosen control set. If any of the device 
drivers should fail to load or initialize then the 
method LoadDeviceDrivers decides whether the 

35 currently executing system boot procedure should 
continue in spite of the failure to properly load or 
initialize the device driver, or whether a new sys- 
tem boot procedure should be initiated using the 
LastKnownGood control set 210 of the registry 107. 

40 The method LoadDeviceDrivers is discussed in 
more detail below and is shown in Figure 9. 

Upon a successful boot of the computer 105, 
using either control set, the method BootSystem, in 
step 607, invokes the method UpdateRegistry. The 

45 method UpdateRegistry, in response to a success- 
ful boot of the computer 105 using the LastKnown- 
Good control set 210, causes the Default control 
set 209 to be set to the Current control set 208 that 
successfully booted the system, and creates a new 

50 LastKnownGood control set 210 that is equivalent 
to the Current control set 208 that successfully 
booted the computer 105. The method Up- 
dateRegistry, in response to a successful boot of 
the computer 105 from the Default control set 209, 

55 creates a new LastKnownGood control set 210 that 
is equivalent to the Current control set 208 which 
successfully booted the computer 105. In this way 
the present invention ensures that the computer 
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105 will successfully boot even after some configu- 
ration data in the Default control set 209 has be- 
come unusable. In step 609, the method Boot- 
System ends processing. However, processing on 
the computer 105, which is unrelated to the method 
BootSystem, can continue. 

Figure 7 is a flow diagram of the method 
ChooseControlSet which chooses a set of configu- 
ration data (i.e., a control set) with which to boot 
the computer 105. The method ChooseControlSet 
will either choose the Default control set 209 or the 
LastKnownGood control set 210 of the registry 107. 
The method ChooseControlSet is preferably per- 
formed by the ChooseControlSet program 113 of 
the operating system 101. 

In step 701 the method ChooseControlSet sets 
the variable UseLastKownGood equal to the value 
False. The variable Use LastKnownGood is set to 
True when the LastKnownGood control set 210 of 
the registry 107 is to be used to boot the computer 
105. The variable UseLastKnownGood is set to 
False when the Default control set 209 of the 
registry 107 is to be used to boot the computer 
105. In step 703, the method ChooseControlSet 
retrieves a LastKnownGood environment variable. 
The LastKnownGood environment variable is set to 
True when the immediately previous attempt to 
boot the computer 105 failed using the Default 
control set 209 of the registry 107, else the Last- 
KnownGood environment variable is set to the val- 
ue False. The LastKnownGood environment vari- 
able is preferably stored in a non-volatile storage 
medium. 

In step 705 the method ChooseControlSet de- 
termines if the user of the computer 105 entered a 
breakin key. The breakin key indicates to the meth- 
od ChooseControlSet that the user wants to view a 
LastKnownGood user interface menu which gives 
the user of the computer 105 the option of booting 
the computer 105 from the LastKnownGood control 
set or booting the computer 105 from the Default 
control set. In the preferred embodiment the 
breakin key is the space-bar and is invoked by 
holding down the space-bar. If the method deter- 
mines that the user did hit the breakin key then, in 
step 706, the method ChooseControlSet displays a 
LastKnownGood user interface menu. The Last- 
KnownGood user interface menu is shown in Fig- 
ure 15. The LastKnownGood user interface menu 
provides the user of the computer 105 with options so 
for booting the computer 105. Using the Last- 
KnownGood user interface menu of Figure 15, the 
user can choose to boot the computer 105 using 
the Default control set 209 of the registry 107 or 
the LastKnown Good control set 117 of the registry 55 
107. Upon completion of step 706, the method 
ChooseControlSet calls the method ManageLast- 
KnownGoodMenu which processes data entries 



from the user which were entered in response to 
LastKnownGood menu options. The method Man- 
ageLastKnownGood is discussed in more detail 
below and is shown in Figure 12. Upon completion 
5 of step 707 the method ChooseControlSet, in step 
709, determines if the variable UseLastKnownGood 
is set equal to the value True. If the variable 
UseLastKnownGood is set equal to the value True 
then in step 711, the method ChooseControlSet 
10 sets the value entry Current 208 of the registry 107 
equal to the control set indicated by the value entry 
LastKnownGood 210 of the registry 107. In this 
way the control set indicated by the value entry 
LastKnownGood 210 is used to boot the system. 
75 Upon completion of step 711 the method 
ChooseControlSet in step 713 returns processing 
control to the method BootSystem of Figure 6. 

Returning to the discussion of step 709, if the 
method ChooseControlSet determines that the vari- 
20 able UseLastKnownGood is set equal to the value 
False then in step 715 the method sets the value 
entry Current 208 equal to the value entry Default 
209. Upon completion of step 715, the method 
ChooseControlSet, in step 713, returns processing 
!5 control to the method BootSystem of Figure 6. 

Returning to the discussion of step 705, if the 
user did not hit the breakin key then in step 717 
the method ChooseControlSet determines whether 
the LastKnownGood environment variable is set 

0 equal to the value True. If the LastKnownGood 
environment variable is set equal to the value 
False, then processing continues with steps 709, 
71 1 , 71 3, and 71 5 (discussed above). 

Returning to the discussion of step 717, if the 
5 LastKnownGood environment variable is set equal 
to the value True then in step 719 the method 
determines whether the value entry AutoSelect 212 
of the registry 107 is set equal to the value True. 
The value entry AutoSelect 212 controls whether 
) the LastKnownGood user interface menu is dis- 
played. If AutoSelect 212 is set equal to the value 
False then steps 701, 707, 708, 711, 713, and 715 
are performed as discussed above. 

If the value entry AutoSelect 212 is set equal to 

1 the value True then in step 721 the variable 
UseLastKnownGood is set to the value True. After 
completion of step 721, steps 709-715 are per- 
formed as discussed above 

Figure 8 is a flow diagram of the method 
InitializeRegistry which obtains configuration data 
for the computer 105 and stores the obtained con- 
figuration data in the registry 107. The stored con- 
figuration data is used by the present invention to 
successfully boot the computer 105. The method 
InitializeRegistry is preferably performed by the 
InitializeRegistry program 1 1 1 of the operating sys- 
tem 101. 
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In step 801 the method InitializeRegistry ob- 
tains configuration data for the computer 105 and 
stores the configuration data in the registry 107. 
Software configuration data is read from the Sys- 
tem hive file and hardware configuration data is 
extracted from the system by computation. The 
store, configuration data is later used to boot the 
computer 105. In step 803 the method In- 
itializeRegistry creates a symbolic link to the con- 
trol set indicated by the value entry Current 208 of 
the registry 107. A symbolic link is a way of 
making all references to a particular key with a 
defined name ("CurrentControlSet") actually refer 
to a different key ("ControlSetnnn") with a different 
name. In step 805 the method InitializeRegistry 
initializes the symbolic link by creating a link from 
the key "CurrentControlSet" to the key at the root 
of the ControlSetnnn control set used to boot the 
system. In step 807 the method InitializeRegistry 
creates the clone 204 by copying the Current con- 
trol set 208 to the clone 204. Upon completion of 
step 807, the method InitializeRegistry, in step 809, 
returns processing control to the method Boot- 
System (Figure 6). 

Figure 9 is a flow diagram of the method 
LoadDeviceDrivers which loads into the computer 
memory 103 and initializes a set of device drivers 
listed in the control set currently being used to 
boot the computer 105. If any of the device drivers 
should fail to load into the computer memory 103 
or should fail to initialize then a decision to con- 
tinue the current boot process or to reboot the 
system using the LastKnownGood control set is 
made. The method LoadDeviceDrivers is preferably 
performed by the LoadDeviceDrivers program 121 
of the operating system 101. 

In step 901 the method LoadDeviceDrivers re- 
trieves, from the control set indicated by the value 
entry Current 208, a list of device drivers to load 
into the computer memory 103 and to initialize. In 
step 903, the method determines if any unproces- 
sed device drivers remain. If unprocessed device 
drivers do remain, then in step 905 the method 
loads the first unprocessed device driver into the 
computer memory 103. In step 907, the method 
determines if the device driver failed to load into 
the computer memory 103. If the device driver 
properly loaded into the computer memory 103, 
then in step 909 the method LoadDeviceDrivers 
calls the method IntializeDeviceDrivers which initial- 
izes the device driver loaded into the computer 
memory 103. The method LoadDeviceDrivers is 
discussed in detail below and is shown in Figure 
10. Upon completion of step 909, processing con- 
tinues with step 903. 

Returning to the discussion of step 907, if the 
device driver failed to load into the computer mem- 
ory 103, then in step 911 the method Load- 



DeviceDrivers calls the method PressOn which de- 
termines whether the system boot procedure cur- 
rently underway should continue in spite of a fail- 
ure to properly load or Initialize a device driver or 

5 whether a new system boot procedure should be 
initiated using the LastKnownGood control set 210 
of the registry 107. The method PressOn is dis- 
cussed in detail below and is shown in Figure 13. 
Upon completion of step 911, the method Load- 

w DeviceDrivers, in step 913, determines if the vari- 
able PressOn which was returned from the method 
PressOn is set equal to the value True. If the 
variable PressOn is set equal to the value False, 
then in step 915, the method LoadDeviceDrivers 

rs reboots the system. However, if the method Load- 
DeviceDrivers determines that the variable PressOn 
is set equal to the value True, then in step 909, the 
method LoadDeviceDrivers calls the method In- 
itializeDeviceDrivers which initializes the device 

20 driver loaded into the computer memory 103. The 
method InitializeDeviceDrivers is discussed in de- 
tail below and is shown in Figure 10. Upon comple- 
tion of step 909 processing continues with step 
903. 

25 If in step 903 the method LoadDeviceDrivers 

determines that all of the device drivers have been 
processed, then in step 917 the method Load- 
DeviceDrivers returns processing control to the 
method BootSystem (Figure 6). 

30 Figure 10 is a flow diagram or the method 

InitializeDeviceDrivers which initialises the device 
driver previously loaded into the computer memory 
103 in the method LoadDeviceDrivers (Figure 9). 
The method InitializeDeviceDrivers is preferably 

35 performed by the InitializeDeviceDrivers program 
139 of the operating system 101 . 

In step 1001 the method InitializeDeviceDrivers 
initializes the device driver previously loaded into 
the memory 103. In step 1003 the method In- 

40 itializeDeviceDrivers determines if the loaded de- 
vice driver failed to initialize properly. If the device 
driver initialized properly then in step 1005, the 
method InitializeDeviceDrivers returns processing 
control to the method LoadDeviceDrivers (Figure 

45 9). 

Returning to the discussion of step 1003, if the 
device driver did fail to initialize properly then in 
step 1007, the method InitializeDeviceDrivers deter- 
mines whether the boot should proceed by calling 
so the method PressOn. The method PressOn is dis- 
cussed in more detail below and is shown in Figure 
13. 

Upon completion of step 1007, the method 
InitializeDeviceDrivers, in step 1009, determines 
55 whether the variable PressOn which was returned 
from the method PressOn is set equal to the value 
True. If the variable PressOn is set equal to the 
value False, then the method In- 
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itializeDeviceDrivers, in step 1011, reboots the sys- 
tem. 

Returning to the discussion of step 1009, if the 
variable PressOn returned from the method Pres- 
sOn is set equal to the value True, then in step 
1005, the method InitializeDeviceDrivers returns 
processing control to the method Load- 
DeviceDrivers of Figure 9. 

Figure 11 is a flow diagram of the method 
UpdateRegistry which, in response to a successful 
boot of the computer 105 using the LastKnown- 
Good control set 210, causes the Default control 
set 209 to be set to the Current control set 208 that 
successfully booted the system, and creates a new 
LastKnownGood control set 210 that is equivalent 
to the Default control set 209 that successfully 
booted the computer 105. In response to a suc- 
cessful boot from the Default control set 209, the 
method UpdateRegistry creates a new LastKnown- 
Good control set 210 that is equivalent to the 
Current control set 208. In this way the present 
invention ensures that the computer 105 will suc- 
cessfully boot even after some configuration data in 
the Default control set 209 has been unusable. 

In step 1101 the method UpdateRegistry calls 
the method UpdateLastKnownGood which updates 
the value entry LastKnownGood 210 of the registry 
107to point to the control set in the registry 107 
which last successfully booted the computer 105. 
The method UpdateLastKnownGood is discussed 
in more detail below and is shown in Figure 14. 
Upon completion of step 1101 the method Up- 
dateRegistry, in step 1103, determines whether the 
computer 105 just successfully booted from the 
control set indicated by the value entry LastKnown- 
Good 210 of the registry 107. System boot is 
preferably considered successful or unsuccessful 
based on a default set of criteria. For example, if 
the system appeared to the operating system 101 
to properly boot but in fact failed because of a 
problem that the operating system cannot detect 
(e.g., the screen is unreadable because the wrong 
video mode is set) then the current boot is not 
considered successful. However, in the preferred 
embodiment, the system boot is considered suc- 
cessful if two criteria are met. First, the system 
must attempt to start all relevant device drivers. If 
any driver fails to start, AND its ErrorControl value 
is Severe or Critical, the boot will NOT be declared 
good. Every device driver has a named node under 
the Services subkey 207 of the System hive, and 
every drivers node contains the value entry Error- 
Control 401 (see Figure 4). ErrorControl has one of 
four values: (1) Ignore, (2) Normal, (3) Severe, and 
(4) Critical. The value Ignore indicates that the 
current system boot should continue, and that even 
if the driver fails to initialize, the user is not notified 
of the failure in the form of a pop-up message. The 



value Normal indicates that the current system 
boot should continue. However, in the preferred 
embodiment a message is displayed to the user 
indicating that an error has occurred during system 

5 boot. The value Severe indicates that the system 
should be rebooted using the LastKnownGood con- 
trol set 210, unless the system is currently being 
booted from the LastKnownGood control set 210, in 
which case the current boot from the LastKnown- 

w Good control set 210 should continue. The value 
Critical indicates that if the system boot is currently 
from the control set identified by the value entry 
Default 209, then the system should be rebooted 
using the LastKnownGood control set 210. The 

75 value Critical also indicates that if the system boot 
is currently from the LastKnownGood control set 
210 that the system boot fails. 

Second, at least one user must successfully 
logon to the system. While the set of criteria set 

20 forth above is the default set of criteria, the pre- 
ferred embodiment also allows the user to define a 
set of criteria for successful boot different than the 
default set discussed above. 

If the computer 105 was successfully booted 

25 from the LastKnownGood control set then, in step 
1105, the method deletes the control set currently 
indicated by the value entry Failed 211 of the 
registry 107. In step 1107 the method sets the 
value entry Failed 211 equal to the data value 

30 contained in the value entry Default 209. In step 
1109 the method sets the value entry Default 209 
equal to the data value of the value entry Last- 
knownGood 210 of the registry 107. In step 1111 
the method UpdateRegistry returns processing 

35 control to the method BootSystem (Figure 6). 

Returning to the discussion of step 1103, if the 
computer 105 successfully booted from a control 
set other than the control set indicated by the value 
entry LastKnownGood 210 then the method Up- 

40 dateRegistry, in step 1111, returns processing con- 
trol to the method BootSystem (Figure 6). 

Figure 12 is a flow diagram of the method 
ManageLastKnownGoodMenu which processes 
user requests entered in response to options pre- 

45 sented in the LastknownGood user interface menu. 
The method ManageLastKnownGoodMenu is pref- 
erably performed by the ManageLastknownGood 
menu program 133 of Figure 1. In step 1201 the 
method ManageLastKnownGood displays the Last- 
so KnownGood user interface menu of Figure 15. In 
step 1203 the method determines whether the user 
of the computer 105 entered a request in response 
to LastKnownGood menu options to boot the com- 
puter 105 from the control set referred to by the 

55 value entry LastKnownGood 210 of the registry 
107. If the user did enter a request to boot the 
computer 105 from the control set referred to by 
the value entry LastKnownGood 210 then in step 
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1205 the method sets the variable UseLastKnown- 
Good equal to the value True. In step 1207 the 
method ManageLastKnown Good Menu returns pro- 
cessing control to the method ChooseControlSet 
(Figure 7). 

Returning to the discussion of step 1203, if the 
user entered a request in response to the Last- 
KnownGood menu to boot the system from the 
control set referred to by the value entry Default 
209 of the registry 107, then in step 1209, the 
method sets the variable UseLastKnownGood equal 
to the value False. Upon completion of step 1209 
the method ManageLastKnown Good Menu, in step 
1207, returns processing control to the method 
ChooseControlSet (Figure 7). 

Figure 13 is a flow diagram of the method 
PressOn which determines whether the system 
boot procedure currently underway should continue 
in spite of a failure to properly load or initialize at 
least one device driver or whether a new system 
boot procedure should be initiated using the Last- 
KnownGood control set 210 of the registry 107. 
The method PressOn determines whether the cur- 
rent system boot procedure should continue by 
testing both a value entry ErrorControl 401 (Figure 
4) associated with each device driver, and by test- 
ing a LastKnownGood environment variable. If the 
driver's ErrorControl is Ignore or Normal, then the 
boot continues. If the driver's ErrorControl is Se- 
vere, and the system is booting from the Default 
control set 209, the boot is failed and the system 
should be rebooted using the LastKnownGood con- 
trol set to retry the boot. If ErrorControl is Severe, 
and the system is booting from the LastKnown- 
Good control set 210, the boot continues. If Error- 
Control is Critical, and the system is booting from 
the Default control set 209, the boot is failed, and 
the system reverts to the LastKnownGood control 
set on the next boot. If the ErrorControl is Critical, 
and the system is booting from the LastKnown- 
Good control set 210, the boot fails entirely. A 
driver's ErrorControl value entry is set when the 
driver is installed, but can be programmatically 
changed at anytime while the system is running. 

The LastKnownGood environment variable in- 
dicates that the system failed to boot from the 
Default control set 209 of the registry 107 and 
should be rebooted using the LastKnownGood con- 
trol set 210 of the registry 107. The LastKnown- 
Good environment variable is preferably stored in 
non-volatile memory. The method PressOn is pref- 
erably performed by the PressOn program 135 of 
Figure 1 . 

In step 1301, the method PressOn determines 
whether the value entry ErrorControl is set equal to 
the value Ignore or the value Normal. If the value 
entry ErrorControl is set equal to the value Normal 
or Ignore, then in step 1303 the method PressOn 



sets the variable PressOn equal to the value True. 
Upon completion of step 1303, the method Pres- 
sOn returns to its caller (i.e., the method Load- 
DeviceDrivers of Figure 9 or the method In- 

5 itialiazeDeviceDrivers of Figure 10). 

Returning to the discussion of step 1301, if the 
value entry ErrorControl is not set equal to the 
value Normal or Ignore, then in step 1307 the 
method PressOn determines whether the value en- 

10 try ErrorControl is set equal to the value Severe. If 
the value entry ErrorControl is set equal to the 
value Severe, then in step 1309 the method Pres- 
sOn determines whether the LastKnownGood envi- 
ronment variable is set equal to the value True. If 

75 the LastKnownGood environment variable is set 
equal to the value True, then in step 1303 the 
method PressOn sets the variable PressOn equal 
to the value True. In step 1305, the method Pres- 
sOn returns to its caller. 

20 Returning to the discussion of step 1 309, if the 

LastKnownGood environment variable is set equal 
to the value False, then in step 1311, the method 
PressOn sets the LastKnownGood environment 
equal to the value True. In step 1313, the method 

25 PressOn sets the variable PressOn equal to the 
value False. Upon completion of step 1313, the 
method PressOn, in step 1305, returns to its caller. 

Returning to the discussion of step 1307, if the 
value entry ErrorControl is not set equal to the 

30 value Severe, then in step 1315, the method Pres- 
sOn determines whether the value entry ErrorCon- 
trol is set equal to the value Critical. If the value 
entry ErrorControl is not set equal to the value 
Critical, then in step 1303, the method PressOn 

35 sets the variable PressOn equal to the value True. 
Upon completion of step 1303, the method Pres- 
sOn, in step 1305, returns to its caller. 

Returning to the discussion of step 1315, if the 
value entry ErrorControl is set equal to the value 

40 Critical, then in step 1317, the method PressOn 
determines whether the LastKnownGood environ- 
ment variable is set equal to the value True. If the 
LastKnownGood environment variable is set equal 
to the value False, then in step 1311, the method 

45 PressOn sets the LastKnownGood environment 
variable equal to the value True. In step 1313, the 
method sets the variable PressOn equal to the 
value False. Upon completion of step 1313, the 
method PressOn, in step 1305, returns to its caller. 

50 Returning to the discussion of step 1317, if the 

method determines that the LastKnownGood envi- 
ronment variable is set equal to the value True, 
then in step 1319, the system crashes. 

Figure 14 is a flow diagram of the method 

55 UpdateLastKnownGood whose primary task is to 
reset the value entry LastKnownGood 210 to point 
to a copy of the clone 204 in order to update the 
LastKnownGood value entry after a successful sys- 
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tern boot using the Current control set 208 of the 
registry 107. The method Update LastKnownGood 
is "preferably performed by the UpdateLastknown- 
Good program 137 of Figure 1. 

In step 1401 the method UpdateLastKnown- 
Good copies the clone 204 from volatile memory to 
non-volatile memory. In step 1403 the method 
flushes the registry 107. A flush of the registry 107 
forces all changes made to a hive, for example, the 
System hive of Figure 2, since the last flush, to be 
committed to disk. The flush is preferably per- 
formed in such a way that either all changes occur, 
or no changes occur. 

In step 1405 the method deletes the control set 
referred to by the value entry LastKnownGood 210 
of the registry 107. In step 1407 the method 
flushes the registry 107. In step 1409 the method 
sets the value entry LastKnownGood 210 of the 
registry 107 to refer to the copy of the Clone 
control set now residing in non-volatile memory. In 
step 1411 the method UpdateLastKnownGood re- 
turns processing control to the method Up- 
dateRegistry (Figure 11). 

Those of ordinary skill in the art will understand 
that other system architectures can be used to 
implement the methods of the present invention 
described above, including, but not limited to, a 
network in which a plurality of computers are coup- 
led with file servers to share access to data among 
computer users through a data communications 
network. 

While the discussion herein focuses on device 
drivers, those of ordinary skill in the art will recog- 
nize that the scope of the discussion is not so 
limited but applies equally to file systems and user 
mode program services. 

It will be appreciated that, although a specific 
embodiment of the invention has been described 
herein for purposes of illustration, various modifica- 
tions may be made without departing from the 
spirit and scope of the invention. 
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The method of claim 1 wherein the step or 
attempting to boot further includes the step of 
determining if the boot is unsuccessful based 
on one of a system defined set of criteria and 
a user defined set of criteria. 

The method of claim 1, further comprising the 
step of: 

updating the first set of configuration data 
so that it is equivalent to the second set of 
configuration data, in response to the success- 
ful boot of the computer system using the 
second set of configuration data. 

The method of claim 3 wherein the step or 
attempting to boot further includes the step of 
determining if the boot is successful based on 
one of a system defined set of criteria and a 
user defined set of criteria. 



5. A method for booting a computer system, the 
method comprising the steps of: 

providing a first set of configuration data to 
be used in a first attempt to boot the computer 

25 system, and a second set of configuration data 

which stores the last set of configuration data 
that successfully booted the computer system; 

attempting to boot the computer system 
from the first set of configuration data; and 

30 in response to a successful boot from the 

first set of configuration data, automatically up- 
dating the second set of configuration data so 
that it is equivalent to the first set of configura- 
tion data which successfully booted the com- 

35 puter system. 

6. The method of claim 5 wherein the step of 
attempting to boot further includes the step of 
determining if the boot is successful based on 

40 one of a system defined set of criteria and a 

user defined set of criteria. 



Claims 

1. A method or booting a computer system, the 
method comprising the steps of: 

providing a first set of configuration data to 
be used in a first attempt to boot the computer 
system, and a second set of configuration data 
which stores the last set of configuration data 
that successfully booted the computer system; 

attempting to boot the computer system 
from the first set of configuration data; and 

in response to an unsuccessful attempt to 
boot the computer system using the first set of 
configuration data, automatically booting the 
computer system from the second set of con- 
figuration data. 



7. A method for booting a computer system, the 
method comprising the steps of: 

45 providing a first set of configuration data to 

be used in a first attempt to boot the computer 
system, and a second set of configuration data 
which stores the last set or configuration data 
that successfully booted the computer system; 

50 attempting to boot the computer system 

from the first set of configuration data; 

determining that the attempt to boot the 
computer system using the first set of configu- 
ration data was unsuccessful; 

55 receiving input data from a user of the 

computer system, the input data indicating that 
the computer system should be booted from 
the second set of configuration data; and 
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in response to the step of receiving, boot- 
ing the computer system from the second set 
or configuration data. 

8. A method for booting a computer system, the 5 
method comprising the steps of: 

providing a registry which stores all data 
needed to boot the computer system, including 
a first set or configuration data to be used in a 
first attempt to boot the computer system, and w 
a second set of configuration data which stores 
the last set of configuration data that success- 
fully booted the computer system; 

assigning data to a third set of configura- 
tion data, the data being equivalent to the data 75 
stored in the first set of configuration data 
before the data stored in the first set of con- 
figuration data is modified; 

attempting to boot the computer system 
from the first set of configuration data; 20 

determining if the boot of the computer 
system from the first set of configuration data 
was successful; and 

in response to a determination that the 
boot of the computer system from the first set 25 
of configuration data was successful, assigning 
data to the second set of configuration data, 
the data being equivalent to the data stored in 
the third set of configuration data. 

30 

9. The method of claim 8 wherein the step of 
attempting to boot the computer system in- 
cludes the step of attempting to load a device 
driver which permits the computer system to 
communicate with a device, and wherein the 35 
step of determining determines that the boot 
was unsuccessful based on a failure to load 
the device driver. 



10. The method of claim 8, further comprising the 40 
step of modifying the data stored in the first 

set of configuration data. 

11. The method of claim 10 wherein the step of 
attempting to boot the computer system from 45 
the first set or configuration data includes the 
step of failing to boot the computer system 

due to the step of modifying causing inac- 
curate data to be stored in the first set of 
configuration data. 50 

12. An apparatus for booting a computer system, 
the apparatus comprising: 

first means for storing a first set of con- 
figuration data to be used in a first attempt to 55 
boot the computer system; 

second means for storing a second set of 
configuration data which stores the last set of 



configuration data that successfully booted the 
computer system; 

means for attempting to boot the computer 
system from the first set of configuration data; 
and 

means for automatically booting the com- 
puter system from the second set of configura- 
tion data in response to an unsuccessful at- 
tempt to boot the computer system using the 
first set of configuration data. 

13. The apparatus of claim 12 wherein the boot is 
considered unsuccessful based on one of a 
system-defined set of criteria and a user-de- 
fined set of criteria. 

14. The apparatus of claim 12, further comprising: 

means for updating the first storing means 
to store as the first set of configuration data 
the second set of configuration data that suc- 
cessfully booted the computer system, in re- 
sponse to the successful boot of the computer 
system using the second set of configuration 
data. 

15. The apparatus of claim 14 wherein the boot is 
considered successful based on one of a sys- 
tem-defined set of criteria and a user-defined 
set of criteria. 

16. An apparatus for booting a computer system, 
the apparatus comprising: 

first means for storing a first set of con- 
figuration data to be used in a first attempt to 
boot the computer system, and second means 
for storing a second set of configuration data 
which stores the last set of configuration data 
hat successfully booted the computer system; 

means for attempting to boot the computer 
system from the first set of configuration data; 
and 

means for automatically updating the sec- 
ond set of configuration data so that it is equiv- 
alent to the first set of configuration data which 
successfully booted the computer system in 
response to a successful boot from the first set 
of configuration data. 

17. The apparatus of claim 16 wherein the boot is 
considered successful based on one of a sys- 
tem-defined set of criteria and a user-defined 
set or criteria. 

18. An apparatus for booting a computer system, 
the apparatus comprising: 

first means for storing a first set of con- 
figuration data to be used in a first attempt to 
boot the computer system; 
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second means for storing a second set of 
configuration data which stores the last set of 
configuration data that successfully booted the 
computer system; 

means for attempting to boot the computer 
system from the first set of configuration data; 

means for determining that the attempt to 
boot the computer system using the first set of 
configuration data was unsuccessful; 

means for receiving input data from a user 
of the computer system, the input data indicat- 
ing that the computer system should be boot- 
ed from the second set of configuration data; 
and 

booting the computer system from the 
second set of configuration data in response to 
the receiving means. 



22. The apparatus of claim 19 wherein means for 
attempting to boot the computer system from 
the first set of configuration data includes 
means or failing to boot the computer system 
due to the means for modifying causing inac- 
curate data to be stored in the first set of 
configuration data. 
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19. An apparatus for booting a computer system 
comprising: 20 

a registry which stores all data needed to 
boot the computer system, including a first set 
of configuration data to be used in a first 
attempt to boot the computer system, and a 
second set of configuration data which stores 25 
the last set of configuration data that success- 
fully booted the computer system; 

means for assigning data to a third set of 
configuration data, the data being equivalent to 
the data stored in the first set of configuration 30 
data before the data stored in the first set of 
configuration data is modified; 

means for attempting to boot the computer 
system from the first set of configuration data; 

means for determining if the boot of the 35 
computer system from the first set of configu- 
ration data was successful; and 

in response to a determination from the 
determining means that the boot of the com- 
puter system from the first set of configuration 40 
data was successful, means for assigning data 
to the second set of configuration data, the 
data being equivalent to the data stored in the 
third set or configuration data. 

45 

20. The apparatus of claim 19 wherein the means 
for attempting to boot the computer system 
includes means for attempting to load a device 
driver which permits the computer system to 
communicate with a device, and wherein the 50 
means for determining determines that the 
boot was unsuccessful based on a failure to 

load the device driver. 



21. The apparatus of claim 19, further comprising 
means for modifying the data stored in the first 
set of configuration data. 
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VHKEY_LOCAL_MACHINE / 
\system 

205 

\selecr ^ 

208 209 

Curreni.p^dwon^ 
Default ■ <dword> — - iU 



LastKnownGoo d = <dword> 1 1 1 

Failed^ <dwora>" 

AutoSeiect = <dword> // i for TRUE, 0 for FALSE 

^ ^204 ^212 
\Clone^ 



^ 201 

\ControlSer001 



\ComrolSet002 ^ 202 



^ 203 
\ControlSet003 ^ 

^ 206 

VcoDtroi 

^207 

Vservices 
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Tree Structure for Control: 
206 
\controI'' 
\machine 

computername = 
timezone = 
\memory_management 



PagedPoolSize = 
NonPagedPoolSize - 
\PageFile 
\1 

Path * <nt path to paging file> 
Size a <size in megabytes 

\2 

Path 3 <m path to paging file> 
Size * <size in megabytes> 

\ pro gram 

autocheck ■ \systemroot\windows\system\autochk.exe* 
autoconven » \systemroot\windows\systemVconvert 

// the names under this key have no particular meaning 

// sm will execute the first token in the values, passing 

// the rest of the tokens as arguments. 

// the programs may be executed in any order sm wishes 

\KnownDU 

DllDirectory = @:\WindowsVSystem 

DUO » base.dU 

Dill = basertLdll 

D112 = gdi.dll 

DU3-user.dll 

DU4 = console.dll 

D1L5 - usemi.dll 

D116-csr.dll 

DI17=»dbgdlLdll 

DIIS = elfapldll 

\Environment 

ComSpec = @:\windows\system\cmd.exe 



\sm 

Debug ■ @:Vwindows\system\dbgss.exe 

Visa 

\dos_devices 

iptl s \device\printerO 
prn = \device\printerO 
com I ■ \device\serialO 



301 



Nservice^group^order^ 

list ■ "scsi j5on\Oscsi jnmi j)ort\0" 



Figure 3 
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Tree Structure for Services: 
207 

\services ^ 
\ub_adapter 
type = adapter 
\Parameters 



AdapterType = NIUpc/EOTP 
Memory window = D8000 
IoPon = 368 
Irqi * 7 

// The value entries under the Parameters key are defined by 

// the drivers that use them, and may be arbitrary. 

// The Driver Conrlg spec will offer conventions for them though. 



\scsi_port 



start « boot 
type = kernel-driver 
group = scsi_port 
ErrorControl = Normal 



^ 401 



\aha5454 



start ■ boot 
type = kernel-driver 
group = scsi_mini_port 
ErrorControl = Normal 



\aha5458 




start = system 
type - driver 
group - scsijninijjort 
ErrorControl « Normal 




Figure 4 



17 



EP 0 636 972 A1 



401 



\<Node_Name> 

Security descriptor for Node_Name allows read'traverse/create subkey 
access to all. but restricts write and create access to System, and administrator 
(Means that services can be create child sub keys under which they set values, 
but cannot set or delete values immediately under the service node 
itself.) 

Type ■ [KERNEL_DRJVER/FILE_SYSTEM DRJVER / WTN32 OWN PROCESS/WIN32 
SHAREJ^ROCESSMDAPTER/RECOGNIZERJDRTVER] ~ 

KERNEL DRIVER is a kernel device driver. ~FILE-SYSTEM»DRTVER is a File 

systems driver. 

WIN32_OWN_PROCESS and WIN32 .SHARE ^PROCESS are Win32 programs that can be started bv the 
service controller and which obeys the service control protocol 

ADAPTER and RECOGNIZERJDRTVER are set of arguments for some piece of hardware. 

Start - [BOOT / SYSTEM / AUTO / DEMAND / DISABLED] 
Ignored for Type = ADAPTER and type = RECOGNIZER DRIVER 

If type - WTN32J) V7N_PROCESS or WTN32_SHAR£ PROCESS Start must be 
one of AUTO.DEMAND.DISABLED. 
BOOT means that this node represents a pan of the driver stack 
for the boot volume, and must therefore be loaded bv os loader 
using the ARC facility (or x86 equiv.) 
SYSTEM means that this node represents a driver to be loaded in 
IoInitSystem. 

AUTO means that this node, regardless of type, is to be loaded or 

started by the service controller, automatically for all boots. 
DEMAND means that this node, regardless of type, is available, 

but will not be started unril the service controller is called to 

start it. 

DISABLED means that this node is not to be started under any 
conditions. 

IraagePath = <pathname> 

Ignored for type = ADAPTER and type = RECOGNIZER DRIVER 
Default is <sysroot> \ driver \ <node_name>.sys for type Driver. 
The path is relative to the system root, unless it begins with\, 

in which case is a fully qualified ARC path for Stan - BOOT, a 

fully qualified NT path for Stan « SYSTEM, or a My qualified 

NT or Win path for any other value of Start 

ObjectName - <objecmame> 

Ignored for type! » ADAPTER and Type = RECOGNIZER DRIVER 

Default is '^driver \ <node.name>'\ Is an NT object manager path 

which specifies the name of the driver object, if Type • KERNEL DRIVER. 
Default is: \FileSystem \ <node jiarae> if type = FELE_SYSTEM DRIVER which specified the name 
of the file system object 

Default is:LocalSystem if Type - WIN32 J)WN_PROCESS or Type - WIN32 SHARE PROCESS 
jvhicjrspecifies the account name for the service process to run with. 
ErrorControl = [CRITICAL \ SEVERE \ NORMAL IGNORE] 

IGNORE boot should proceed if the node fails to load or initialize, but user is not notified of Mure. 
NORMAL boot should proceed if the node fails to load or initialize. 
SEVERE if boot is not based on Last Known Good control set 
fail it (ue. Switch to Last Known Good and try again.) 
If this is a Last Known Good attempt, press on in case of 
error. 

CRITICAL fail boot. If not Last Known Good, try Last Known Good 
If boot is Last Known good, bugcheck. 

Figure 5 
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Boot System 
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ChooseControlSet 
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InitializeRegistry 
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LoadDeviceDrivers 
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UpdateRegisty 


> 
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^ Return J 



Figure 6 
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^ ChooseControlSe^ 



701 



UseLastKnownGood 
= False 




Set 

UseLastKnownGood 
= True 




Yes 



Set 

Current = Default 
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Display 
LastKnownGood 
Menu 



707 



Manage 
LastKnownGood 
Menu 



711 



Set Current = 
LastKnownGood 



Figure 7 
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Initialize 
Registry 



> 
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Obtain the 
Configuration Data 

and Store the 
Configuration Data 

in the Registry 
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Create Current 
Control Set 
Symbolic Link 


> 
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Initialize Current 
Control Set 
Symbolic Link 
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Create the Clone 
Control Set by 
Copying the Current 
Control Set to the 
Clone Control Set 



^-809 



^ Return ^ 



Figure 8 
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Load 
Device Drivers 



901 



Retrieve from the 
Current Control 
Set a List of Device 
Drivers to Load 
and to Initialize 




Load the First 
Unprocessed 
Device Driver 
Into Memory 




Initialize 
Device 
Drivers 



915 



Reboot 
the System 



^917 



^ Return ^ 

Figure 9 
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1001 



Initialize the 
Device Driver 
Previously Loaded 
Into Memory 





Figure 10 
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1101 




-1105 



1107 



1109 



^ Return J 
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Figure 11 
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Display 
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Menu 




^ Return ^ 
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Figure 13 
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Update 
I LasiKnownGood ) 
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Copy the Clone 
Control Set from 
Volatile Memory 
to a Control Set 
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Flush the 
Registry 


> 
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Delete the Control 
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Set 

LastKnownGood 
Value Entry to 
Refer to the Clone 
Control Set Now 
Residing in 
Non-Volatile 
Memory 




Figure 14 
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You may now select to boot the system using the Last Known 
Good configuration. If you chose to boot from the Last 
Known Good configuration, any configuration changes since 
the system was last successfully booted will be lost. 

Use Current Configuration 

Use Last Known Good Configuration 
Reboot 

Use the up and down arrow keys to make your selection. 
Please press enter when you have made your selection. 



Figure 15 
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